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This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 
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Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2005). 

Abstract 
Mobile IPv4 message types range from 0 to 255. This document 
reserves a message type for use by an individual, company, or 


organization for experimental purposes, to evaluate enhancements to 
Mobile IPv4 messages before a formal standards proposal is issued. 
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1. Introduction 


Mobile IPv4 message types range from 0 to 255. This document 


reserves 


a message type for experimental purposes, to evaluate 


enhancements to Mobile IPv4 messages before a formal standards 


proposal 


is issued. 


Without experimental message capability, one would have to select a 
type value from the range defined for IANA assignment, which may 
result in collisions. 


Within a message, Mobile IP defines a general extension mechanism 


allowing 


messages. 


127] and 
document 


optional information to be carried by Mobile IP control 
Extensions are not skippable if defined in the range [0- 
are skippable if defined in the range [128-255]. This 
reserves extension types in both the skippable and non- 


skippable ranges for experimental use. 


Mobile IPv4 defines error codes for use by the FA [64-127] and HA 
[128-192]. This document reserves an error code in both of these 
ranges for experimental use. 


The definition of experimental numbers in this document is made 
according to the recommendation of Section 2.2 of BCP 82, RFC 3692. 
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2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [1]. 


In addition, this document frequently uses the following terms: 


EXP-MSG-TYPE: A Mobile-IPv4 message number assigned for experimental 
use. IANA has assigned message number 255 for this. 


EXP-SKIP-EXT-TYPE: A Mobile-IPv4 and ICMP router discovery Agent 
Advertisement extension number assigned for experimental use. IANA 
has assigned extension number 255 for this. 


EXP-NONSKIP-EXT-TYPE: A Mobile-IPv4 and ICMP router discovery Agent 
Advertisement extension number for experimental use. IANA has 
assigned extension number 127 for this. 


EXP-HA-ERROR-CODE: A Mobile-IPv4 error code for use by the HA in 
MIPv4 reply messages to indicate an error condition. IANA has 
assigned error code 192 for this. 


EXP-FA-ERROR-CODE: A Mobile-IPv4 error code for use by FA in reply 
messages to indicate an error condition. IANA has assigned error 
code 127 for this. 


Mobility Entity: Entities as defined in [2] (home agent, foreign 
agent, and mobile node). 


3. Experimental Message 


As the nature and purpose of an experimental message cannot be known 
in advance, the structure is defined as having an opaque payload. 
Entities implementing the message can interpret the message according 
to their implementation. Interpreting based on extensions present in 
the message is one suggestion. 


These messages may be used between the mobility entities (Home Agent, 
Foreign Agent, and Mobile Node). Experimental messages MUST be 
authenticated using any of the authentication mechanisms defined for 
Mobile IP ([2], [5]). 


This message MAY contain extensions defined in Mobile IP, including 
vendor-specific extensions [4]. 
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IP fields: 


Source Address: Typically the interface address from which 
the message is sent. 


Destination Address: The address of the agent or the Mobile 
Node. 


UDP fields: 
Source Port Set according to RFC 768 (variable) 
Destination Port Set to the value 434 


Mobile IP fields shown below follow the UDP header. 


0 1 2 3 

Oecd 2. S024) 25: E T 48-950) e 234, B52 6 G 9 Ot D238! AS 6st 180980. L 
+-+-—4+-4+-—+-—4+-4t-4+-4+-4+-4t-4-4+-t-t—4-t-t-t-4+-t-t-t-t-t-t-4t-t-t-4+-t-t-+ 

| Type | Opaque. 
+—+-—4+-4+-—+-4+-4+-4+-4+-4+-4t-—4+-4+-t-4t-4+-4+-t-4t-4+-t-t-4+-4t-4t-4-4+-t-t-4+-4t-4t-4+ 
Type 255 (EXP-MSG-TYPE) 

Opaque Zero or more octets of data, with structure defined only 


by the particular experiment it is used for. 


Once an experimental message has been tested and shown to be useful, 
a permanent number should be obtained through the normal IANA numbers 
assignment procedures. 


A single experimental message type is defined. This message can 
contain extensions based on which the message can be interpreted. 


Up-to-date values for the message types for Mobile IP control 
messages are specified in the most recent "Assigned Numbers" [3]. 


4. Experimental Extensions 


This document reserves Mobile IPv4 extensions in both the skippable 
and non-skippable ranges for experimental purposes. The long 
extension format (for non-skippable extensions) and short extension 
format (for skippable extensions), as defined by [2], are used for 
Mobile IPv4 experimental extensions. 


Also, ICMP router discovery extension numbers in both the skippable 
and non-skippable ranges are reserved for experimental use. 


Patel & Leung Standards Track [Page 4] 


RFC 4064 Experimental Message, Extensions, and Error Codes 


4.1. Non-skippable Mobile IPv4 Experimental Extension 


May 2005 


This format is applicable for non-skippable extensions and may carry 


information more than 256 bytes. 


m 
N 
+ W 


5 67 8 
+-+-+-4+- 
| Sub-Type Length 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Opaque. 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+- 


PERTE O 
+ 
l 
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Type 127 (EXP-NONSKIP-EXT-TYPE) is the type, which 
experimental extension. 


+-+- 


O w 


+ 


-+-+ 


-+-+ 


+-+-+-+-+ 


describes an 


Sub-Type A unique number given to each member in the aggregated 


type. 

Length Indicates the length (in bytes) of the data field within 
this extension. It does NOT include the Type, Sub-Type, 
and Length fields. 

Opaque Zero or more octets of data, with structure defined only by 


the particular experiment it is used for. 


As the length field is 16 bits wide, the extension data can exceed 


256 bytes in length. 
4.2. Non-skippable ICMP Router Discovery Exp. Extension 
This format is applicable for non-skippable extensions. 


2 
901 
+-+-+- 


Length 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


0 

0 6 
+-+- -+-+-+-+-+- 
| | Opaque 
+ + 


-+-+-+-+-+-+-+-+-+-+-+-+-+- 


O 


+ 


+ 


-+-+ 


-+-+ 


Type 127 (EXP-NONSKIP-EXT-TYPE) is the type, which describes an 


ICMP router discovery experimental extension. 


Length Indicates the length (in bytes) of the data field within 
this extension. It does NOT include the Type and Length 


fields. 
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Opaque Zero or more octets of data, with structure defined only by 
the particular experiment it is used for. 


A node that receives a router advertisement with this extension 
should ignore the extension if it does not recognize it. 


A mobility entity that understands this extension but does not 
recognize it should drop (ignore) the router advertisement. 


4.3. Skippable Mobile IPv4 Experimental Extension 


This format is applicable for skippable extensions, which carry 
information less than 256 bytes. 


+ 0 
O w 
H 


Length Sub-Type 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


0 
0 
+-+- 
+ -+-+-+-+-+-+ 


Type 255 (EXP-SKIP-EXT-TYPE) is the type, which describes an 
experimental extension. 


Length Indicates the length (in bytes) of the data field within 
this extension. It does NOT include the Type and Length 
fields. 


Sub-Type A unique number given to each member in the aggregated type. 


Opaque Zero or more octets of data, with structure defined only by 
the particular experiment it is used for. 


As the length field is 8 bits wide, the extension data cannot exceed 
256 bytes in length. 


4.4. Skippable ICMP Router Discovery Experimental Extension 
This format is applicable for skippable ICMP router discovery 


extensions. This extension should be ignored if an implementation 
does not understand it. 
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0 1 2 3 

0.4 23°45 607 g 9.01. 2 3A 6 7589 Oo 1 23 45 67 8-920: L 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Opaque. 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type 255 (EXP-SKIP-EXT-TYPE) is the type, which describes an 


experimental extension. 


Length Indicates the length (in bytes) of the data field within 
this extension. It does NOT include the Type and Length 
fields. 


Opaque Zero or more octets of data, with structure defined only by 
the particular experiment it is used for. 


5. Experimental Error Codes 


This document reserves the reply error code EXP-FA-ERROR-CODE for use 
by the FA. This document also reserves the reply error code EXP-HA- 
ERROR-CODE for use by the HA. 


These experimental error codes may be used in registration reply 
messages. 


It is recommended that experimental error codes be used with 
experimental messages and extensions whenever none of the 
standardized error codes are applicable. 


6. Mobility Entity Considerations 


Mobility entities can send and receive experimental messages. 
Implementations that don’t understand the message type SHOULD 
silently discard the message. 


Experimental extensions can be carried in experimental messages and 
standards-defined messages. In the latter case, it is suggested that 
experimental extensions MUST NOT be used in deployed products and 
that usage be restricted to experiments only. 


7. IANA Considerations 


This document defines a control message to be used between mobility 
entities, two new extension formats, and two new error codes. To 
ensure correct interoperation based on this specification, IANA has 
reserved values in the Mobile IPv4 number space, as defined in [2], 
for one new message type, two new extensions, and two error codes. 
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7.1. New Message Type 


A new Mobile IPv4 control message using UDP port 434, type 255 (EXP- 
MSG-TYPE), has been defined by IANA. This value has been taken from 
the same number space as Mobile IP Registration Request (Type = 1) 
and Mobile IP Registration Reply (Type = 3). 


7.2. New Extension Values 
The following extension types are introduced by this specification: 


Experimental non-skippable extension: The value 127 (EXP-NONSKIP- 
EXT-TYPE) has been assigned from the numbering space for non- 
skippable extensions, which may appear in Mobile IPv4 control 
messages. 


Also, the same number, 127 (EXP-NONSKIP-EXT-TYPE), has been assigned 
from the numbering space for non-skippable extensions, which may 
appear in ICMP router discovery messages. 


Experimental skippable extension: The value 255 (EXP-SKIP-EXT-TYPE) 
has been assigned from the numbering space for skippable extensions, 
which may appear in Mobile IPv4 control messages. 


Also, the same number, 255 (EXP-SKIP-EXT-TYPE), has been assigned 
from the numbering space for skippable extensions, which may appear 
in ICMP router discovery messages. 


7.3. New Error Codes 


The value 192 (EXP-HA-ERROR-CODE) has been defined by IANA to be used 
as a code field in messages generated by HA. 


Also, the value 127 (EXP-FA-ERROR-CODE) has been defined by IANA to 
be used as the code field in messages generated by the FA. 


8. Security Considerations 
Like all Mobile IP control messages, the experimental messages MUST 
be authenticated per the requirements specified in [2] or [5]. 


Experimental messages without a valid authenticator SHOULD be 
discarded. 
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Backward Compatibility Considerations 


Mobility entities that don’t understand the experimental message MUST 
silently discard it. 


Mobility entities that don’t understand the experimental skippable 
extensions MUST ignore them. Mobility entities that don’t understand 
the non-skippable experimental extensions MUST silently discard the 
message containing them. This behavior is consistent with section 
1.8 of [2]. 


Foreign Agents and Home Agents SHOULD include an experimental error 
code in a reply message only if they have a general indication that 
the receiving entity would be able to parse it. This is indicated if 
the request message was of type EXP-MSG-TYPE or contained at least 
one experimental extension. 
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